The present invention relates to a method for authenticating a software package supplied by a software provider, containing a software component loadable into a terminal, the software component being provided with an authentication suffix, which may be verified to perform an authentication check in the terminal. A higher-level authenticating site may be provided that performs authenticating measures on the software package to increase security.
Such a method is described in German Patent DE 101 40 721 A1, for example, for providing software for use by a control unit in a motor vehicle. The basic task of such authentication methods is to ensure that no unauthorized and/or harmful software components are loaded into a software-controlled terminal. This problem is of great urgency in the automotive field in particular, because modern vehicles are equipped with a plurality of software-controlled control units, the correct functioning of which is a prerequisite for safe operation of a vehicle. Loading unauthorized software may constitute a considerable safety risk. Furthermore, many performance and/or comfort features of modern vehicles are software based.
In other words, vehicles are equipped with hardware suitable for a high level of performance and/or comfort, but the hardware is controlled by the software individually according to customer specifications, and optionally as a billable function. The corresponding software may be loaded either individually into the corresponding control units or preinstalled software may be activated individually, e.g., by loading so-called release codes. Substantial economic loss may be incurred by the vehicle manufacturers as a result of unauthorized loading and/or release of software, if it is done without payment of the required fees. On the other hand, the work-sharing industrial and social structure requires outsourcing of many essential tasks to suppliers, workshops, etc., so an authentication system is necessary to ensure strict control of the implementation of software in terminals on the one hand, while also permitting the required flexibility for a customer-friendly service management on the other hand.
With the known method, a software signature site, in particular, the software manufacturer, will sign the software components to be loaded, e.g., program codes and/or release codes, with a private key and will forward the software signed in this way to a higher-level authenticating site, e.g., the so-called trust center with the vehicle manufacturer. The signature of the software provider is checked and the signature is “certified” at the trust center. This “certification” is performed in the form of a suffix to a trust center certificate which contains, ill addition to a signature prepared using a private key of the trust center, preferably, the public key of the software provider and one or more validity restrictions for the software component.
When loading the software component, the trust center signature is first checked by using a public key for the trust center stored in the terminal. With the help of the public key that has been provided by the software provider, its signature is checked and any encoded areas of the software package are decoded. Finally, the software component is installed, taking into account the validity restrictions transmitted with the trust center certificate.
This method has the disadvantage that each terminal must be capable of processing both the signatures/certificates of the trust center as well as those of the software provider. With the multitude of different terminals from different manufacturers and an equally large number of different software providers, this requires an enormous complexity in the design of each terminal. Or, on the other hand, it requires a technical link to certain suppliers which can thereby secure for themselves a de facto supplier monopoly by creating their own standards.
Therefore, it is an object of the present invention to improve upon a generic authentication method so that the flexibility of the system as a whole is increased without any sacrifice in terms of security, and the design of individual system components is simplified.
This object may be achieved, in part, because the measures implemented by a higher-level authenticating site include providing a software package with at least one second authentication suffix instead of a first authentication suffix, after successful testing of the software package supplied by a software provider and comprising a first authentication suffix in addition to a software component. This means that the particular terminals are released from the task of having to interpret and take into account the authentication suffixes, e.g., signatures and/or certificates of the software provider. Instead of the usual “certification” of certificates, signatures, etc. of the software providers, these are replaced according to the present invention by authentication suffixes issued centrally, e.g., by the trust center. Therefore, the terminals need only be compatible with the signature and/or certification method used by the trust center and accordingly may be designed to be simpler than in the past. At the same time, however, this does not result in a security gap, because the central authentication suffix is not issued until after the authentication suffixes of the software provider have been checked. This also offers the possibility of responding quickly to changes in authorization of individual software providers for providing software.
It should be noted that the terms “replace” and “instead of” an authentication suffix refer here to a functional replacement. This is preferably, but not necessarily, associated with a physical replacement of the corresponding data in the software package. The inventive task is also fulfilled, however, by setting up the system as a whole, so that when the software component is loaded into the terminal, only the authentication suffixes of the trust center are taken into account and the authentication suffixes of the software provider that have already been checked by the trust center are ignored.
As mentioned above, the inventive method offers the possibility that checking of the software package by the higher-level authenticating site may include checking the current authorization of the software provider for providing software components. In an exemplary refinement of the inventive method, this option is in fact implemented.
In an exemplary embodiment of the present invention, the method is designed according to the PKI concept (PKI=public key infrastructure). It is possible to provide here for the first authentication suffix of the software package provided by the software provider to be encoded at least partially with a key that is a private key for this provider and can be decoded with a public key known to the higher-level authenticating site. This corresponds to signing or certifying under the known PKI concept. The public key of the software provider may be transmitted to the higher-level authenticating site within the context of a certificate or brought to the attention of same by another method so that instead of a certificate, a simple signing by the software provider is sufficient.
In a logical refinement of the PKI concept, it is possible in an embodiment of the inventive method for the at least second authentication suffix to be encoded by the higher-level authenticating site using at least partially a key that is private for this site and can be decoded using a public key known in the terminal. Here again, if there is no encryption for confidentiality reasons, the public key may be transmitted by way of a certificate. On the other hand, it is also possible to store the public key in an inaccessible memory area of the terminal, i.e., protected by confidentiality.
The basic idea of the inventive method allows a high measure of flexibility. In particular, it is possible to create an authentication hierarchy within the higher-level authenticating site. Thus, in an advantageous embodiment, for example, it is possible for the software package to be provided with multiple authentication suffixes in succession by the higher-level authenticating site, in which an authentication suffix with which the software package has been provided at an earlier point in time is used to perform an authentication check prior to subsequently providing the software package with an authentication suffix. This allows, for example, a system of signing and “certifying,” which may be designed in two or more steps, within the higher-level authenticating site.
If such a hierarchically structured authentication concept is used, it is advantageous if an authentication check using multiple authentication suffixes of the higher-level authenticating site is performed when loading the software component into the terminal and/or when executing the software component in the terminal. In other words, this means that the multistage authentication can be implemented and/or verified in the terminal, but as a positive effect of the present invention, only compatibility with the signature and/or certification methods used by the higher-level authenticating site is required.
As already mentioned above, there is the possibility that an authentication suffix appended by the higher-level authenticating site may contain data based on a restriction of the functionality of the software component in question. In the case of an advantageous embodiment of the inventive method, this option is in fact implemented. The restrictions on functionality or validity may pertain to the release of certain applications and optionally even version states of the particular applications. In addition, individualization is also possible based on the vehicle (e.g., via the vehicle identification number) or certain vehicle models and/or one or more control units or types of control units (e.g., via a control unit number), based on individual persons (e.g., via an individualized chip card, e.g., integrated into the vehicle key) or via a GSM card in the vehicle telephone. In addition, temporary restrictions on validity may also be incorporated. Examples include limited validity for a certain period of time, for a certain number of hours of operation, a certain number of kilometers or (application specific) a certain number of function retrievals. In addition, selective validity restrictions may also be provided, i.e., application-specific restrictions in the sense of a demo version or a version having a reduced function scope. Finally, there is also the possibility of a regional restriction on validity which may be coupled to the current location of a vehicle. Such restrictions on validity and/or functionality are effective in particular when the terminal does not perform a validity check or does so not only at the time of the initial loading of the software components but must also perform it repeatedly during subsequent operation. A Boolean linkage of multiple validity restrictions is, of course, also possible.
The software components to be loaded into the terminal may contain, for example, program codes and/or release codes for program codes installed in the terminal.
As already indicated above, the terminal is preferably a control unit in a motor vehicle, where the term “control unit” is understood to refer to control units in the actual sense for triggering certain vehicle components as well as other convenience equipment, such as navigation systems or information systems.
Other objects, advantages and novel features of the present invention will become apparent from the following detailed description of the invention when considered in conjunction with the accompanying drawing.